Mon approche pédagogique repose sur quelques principes, que j’ai essayé de mettre en oeuvre dans cet ouvrage :

Aucune connaissance particulière d’UML™ n’est nécessaire, même si j’y fais référence à plusieurs endroits pour les étudiants qui connaissent cette notation (quasiment enseignée partout maintenant comme langage de modélisation). Il s’agit d’un parti pris prenant en compte plusieurs points :

Vous trouverez en fin d’ouvrage un ensemble de liens utiles (cf. [liens]) et de références (cf. [refs]). Sinon, vous pouvez aussi constatez les évolutions de l’intérêt pour SysML™ grâce aux "trends". Voici les dernières tendances au moment où nous écrivons ces lignes
[Ou bien utilisez les URLs comme http://www.google.fr/trends/explore#q=sysml.]
:

À noter également que l’OMG™ a réalisé en 2009 une enquête sur l’utilisation de SysML™
[http://www.omgsysml.org/SysML_2009_RFI_Response_Summary-bone-cloutier.pdf]
dont voici deux extraits :

Cet ouvrage est tout à fait utilisable dans le cadre des ces cours. Pour STI2D, seul un sous-ensemble des diagrammes de SysML™ a été retenu. Les élèves et les enseignants du bac STI2D pourront trouver dans ce document des éléments utiles sur ces diagrammes :

Ces 6 diagrammes sont tous traités dans cet ouvrage à un niveau qui devrait correspondre à l’utilisation qui en est faite en STI2D.

Ils servent trois objectifs principaux inscrits au programme et dont les élèves pourront également trouver des éléments de réflexion :

L’Union des Professeurs de Sciences et Techniques Industrielles (UPSTI) prépare à leur où nous écrivons ces lignes un document de cadrage en terme de méthodologie et de démarche. Nous n’insisterons donc pas sur ces aspects, mais donnerons quelques pistes dans le chapitre commun sur les conseils d’enseignement Pédagogie.

Notons que dans ce cadre là, les 9 diagrammes sont utilisables même si pour l’instant les diagrammes paramétriques et de paquetages sont un peu mis en retrait.

Les questions et exercices de fin de chapitres de la partie notation seront peut-être d’un niveau plus avancé pour servir véritablement d’exercices, mais pourront amener à une réflexion encadrée par l’enseignant.

Le système CMS (crash management system) est un système distribué de gestion d’accidents qui est responsable de la coordination et de la communication entre un coordinateur présent dans une caserne de pompiers (appelé FSC pour Fire Station Coordinator) et un autre présent dans un poste de police (appelé PSC pour Police Station Coordinator) afin de gérer une crise dans un délai raisonnable.

La communication interne entre les membres de la police (y compris le PSC) est en dehors du domaine qui nous intéresse ici (la gestion de crise). La même hypothèse s’applique aux communications internes ou avec des acteurs externes côté pompiers (y compris le FSC). Les informations concernant la crise ainsi que tout ce qui a trait aux tâches des coordinateurs sont mises à jour et maintenues pendant et après la crise.

Il n’existe pas de base de données centrale; caserne de pompiers et police ayant leur base de données respectives distinctes et seulement accessible aux autre à travers le système CMS. Chaque processus de coordination est donc en charge de l’ajout et la mise à jour des informations dans sa base de données respective.

CMS commence à fonctionner au moment où une crise donnée a été détectée et déclarée à la fois à la caserne de pompiers et au poste de police.

Toutes les caractéristiques des différents acteurs sont détaillées ci-dessous.

Dans un axe horizontal, j’ai différencié quatre grands points de vue :

Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :

Que ce soit généralement en terme de cycle de développement ou historiquement, l’Ingénierie Système arrive avant l’Ingénierie Logicielle. Les ingénieurs systèmes ont donc une longue expérience et des pratiques bien ancrées.

On parle de système complexe lorsque l’on a affaire à :

On parle aussi de Système de systèmes quand un système :

Toute la question que l’Ingénierie Système cherche à résoudre est : comment passer des exigences au système de la façon la plus efficace possible.

Pour cela l’Ingénierie Système est découpée en plusieurs analyses, chacune avec un but bien particulier :

Pour arriver à combler le gap entre le système à développer et ses spécifications.

Voici à quoi pourrait ressembler la fiche d’identité de SysML™ :

La figure suivante, tirée de la spécification, résume bien les liens entre SysML™ et UML™, à savoir que SysML™ reprend une partie seulement des concepts d’UML™ (appelée UML4SysML) en y ajoutant des concepts nouveaux.

SysML™ n’est pas une palette de dessins et d'éléments de base servant à faire des diagrammes. Il existe une représentation graphique des éléments modélisés en SysML™. Elle est importante car elle permet de communiquer visuellement sur le système en développement, mais du point de vue du concepteur, c’est le modèle qui importe le plus.

C’est pourquoi nous vous recommandons de ne jamais "dessiner" des diagrammes SysML™
[Sauf bien sûr au brouillon ou sur un tableau, notamment quand on travaille en équipe.]
, mais d’utiliser des outils dédiés (cf. [Outils]).

Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la [Matrice]) :

On abordera :

Le diagramme de paquetage permet de représenter l’organisation des modèles en paquetages.

Les modèles peuvent être organisés selon toutes sortes de considération (cf. [organisation]) :

Il existe plusieurs types de package :

Les modèles peuvent être organisés selon toutes sortes de considération :

Un package permet de créer un espace de nommage pour tous les éléments qu’il contient. Ainsi, dans un package, on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguité.

Pour éviter toute ambiguité, on peut utiliser pour les éléments de modèles leur nom complet (Qualified name), c’est à dire le nom de l'élément préfixé par son (ou ses) package(s) (e.g., Structure::Products::Clock).

Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :

SysML™ propose un certain nombre de mécanismes pour organiser les différents modèles, tirés pour la plupart d’UML™. Ces mécanismes seront plus faciles à comprendre au travers de leur utilisation concrète dans la suite.

On abordera :

Il ne s’agit pas ici de revenir sur les exigences elles-même, mais plutôt de voir comment SysML™ permet de les exprimer, de les manipuler et surtout de les lier avec le reste du système.

Il est possible d’indiquer un certain nombre de propriétés sur un requirement :

Les principales relations entre requirement sont :

Il existe ensuite les relations entre les besoins et les autres éléments de modélisation (les block principalement) comme <<satisfy>> ou <<verify>>, mais nous les aborderons dans la partie transverse.

Voici un exemple de req un peu plus étoffé, tiré de http://www.uml-sysml.org/sysml (voir aussi [rationale]) :

Tout comme pour n’importe quel bloc, il est possible de stéréotyper les requirements. Ceci permet de se définir ses propres priorités et classifications. Quelques exemples de stéréotypes utiles :

Il est possible d’annoter les éléments de modélisation en précisant les raisons (rationale) ou les éventuels problèmes anticipés (problem).

Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases (en utilisant <<refine>> par exemple) et aux éléments structurels (en utilisant <<satisfy>> par exemple), mais ceci sera abordé dans la partie [transvers].

Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.

Ce diagramme est exactement identique à celui d’UML™.

Les exigences sont très importantes en ingénierie système, plus en tout cas qu’en ingénierie logiciel, du fait de la multiplication des sous-systèmes et donc des intermédiaires (fournisseurs, sous-traitants, etc.) avec qui les aspects contractuels seront souvent basés sur ces exigences. Il n’est donc pas étonnant qu’un diagramme et des mécanismes dédiés aient été prévus en SysML™.

En terme de démarche, il est classique d’avoir de nombreux aller-retour entre la modélisation des exigences et la modélisation du système lui-même (cf. [sysmod]).

On abordera :

En terme d’organisation, le mécanisme clef est celui de package. Celui-ci va permettre d’organiser les modèles, pas le système lui-même. Nous avons abordé cette organisation (cf. [package]).

Pour l’organisation du système, on trouve le plus souvent :

Un ibd décrit la structure interne d’un bloc sous forme de :

Afin de capturer de manière précise les contraintes entre valeurs, ou encore les liens entre les sorties et les entrées d’un bloc, SysML™ utilise trois concepts clefs :

Les diagrammes de séquence système (DSS) sont des Sequence Diagrams UML™ classiques où seul le système est représenté comme une boîte noire en interaction avec son environnement (les utilisateurs généralement).

Il permet de décrire les scénarios des cas d’utilisation sans entrer dans les détails. Il convient donc mieux à l’ingénierie système qu’un diagramme de séquence classique (cf. section sur les [seq]).

En résumé, il existe plusieurs diagrammes permettant d’exprimer la structure du système à concevoir. En fonction du niveau de détail nécessaire on peut voir les sous-systèmes comme des boîtes noires (des blocs) ou comme des boîtes blanches (grâce à l'ibd correspondant).

On abordera :

Les éléments de base :

Le Diagramme des Cas d’Utilisation est un diagramme UML™ permettant de représenter :

SysML™ a repris le concept, déjà connu en UML™, de machine à états (State Machines). Ce diagramme représente les différents états possibles d’un bloc particulier, et comment ce bloc réagit à des événements en fonction de son état courant (en passant éventuellement dans un nouvel état). Cette réaction (nommée transition) possède un événement déclencheur, une condition (garde), un effet et un état cible.

Le diagramme d’états comprend également deux pseudo-états :

Lorsqu’un état nécessite lui-même plus de détails, on créé un état composite (aussi appelé super-état) qui est lui-même une machine à état. On peut ainsi factoriser des transitions déclenchées par le même événement (et amenant vers le même état cible), tout en spécifiant des transitions particulières entre les sous-états. Il est également possible d’attacher un diagramme d'état (composite) à un état pour garder une représentation hiérarchique.

Un diagramme d'état peut représenter des régions concurrentes (dont les activités peuvent évoluer en parallèle), graphiquement représentées par des zones séparées par des traits pointillés. Chaque région contient ses propres états et transitions.

Il existe encore d’autres concepts avancés que nous ne présenterons pas dans cette introduction car ils sont beaucoup moins utilisés (entry, exit, transition interne, etc.).

Les diagrammes d’activité (Activity Diagrams) est utilisé pour représenter les flots de données et de contrôle entre les actions. Il est utilisé pour raffiner en général un cas d’utilisation. Il est utilisé pour l’expression de la logique de contrôle et d’entrées/sorties. Le diagramme d’activité sert non seulement à préciser la séquence d’actions à réaliser, mais aussi ce qui est produit, consommé ou transformé au cours de l’exécution de cette activité.

Les éléments de base du diagramme d’activité sont :

Les actions sont les unités fondamentales pour spécifier les comportements en SysML™. Une action représente un traitement ou une transformation. Les actions sont contenues dans les activités, qui leur servent alors de contexte.

Un flot de contrôle permet le contrôle de l’exécution des noeuds d’activités. Les flots de contrôle sont des flèches reliant deux noeuds (actions, décisions, etc.).

Le diagramme d’activité permet également d’utiliser des flots d’objets (reliant une action et un objet consommé ou produit). Les object flow, associés aux broches d’entrée/sortie (input/output pin) permettent alors de décrire les transformations sur les objets manipulés.

Pour permettre la modélisation des flots continus, SysML™ ajoute à UML™ la possibilité de caractériser la nature du débit qui circule sur le flot : continu (par exemple, courant électrique, fluide, etc.) ou discret (par exemple, évenements, requêtes, etc.). On utilise pour cela des stéréotypes : <<continuous>> et <<discrete>>. Par défaut, un flot est supposé discret.

Une décision est un noeud de contrôle représentant un choix dynamique entre plusieurs conditions (mutuellement exclusives). Elle est représentée par un losange qui possède un arc entrant et plusieurs arcs sortants. Il existe plusieurs noeuds de contrôle (cf. [Control]) :

Les activités peuvent être réutilisées à travers des actions d’appel (callBehaviorAction). L’action d’appel est représentée graphiquement par une fourche à droite de la boîte d’action, ainsi que par la chaîne : nom d’action : nom d’activité. SysML™ propose encore bien d’autres concepts et notations, comme la région interruptible, la région d’expansion ou encore les flots de type stream qui sortent du cadre de ce livre d’introduction.

Il existe de nombreux diagrammes pour exprimer les comportements. Ces modèles sont importants dans la mesure où ils peuvent servir à valider le futur système vis-à-vis de ces comportements exprimés. Ils ne sont donc véritablement utiles que lorsqu’ils sont couplés à des outils de simulation ou d’analyse (cf. [Analyse]).

On abordera ici les aspects transversaux comme :

Nous avons vu déjà un certain nombre de mécanismes SysML™ qui permettent de tracer les exigences. Nous les regroupons ici dans une matrice spécifique (qui se lit dans le sens des relations, par exemple un élément de structure comme un bloc <<satisfy>> une exigence).

Comme indiqué dans le tableau ci-dessus, en général, le lien de raffinement est utilisé entre une exigence et un élément comportemental (état, activité, uc, etc.) tandis que l’allocation concerne principalement les éléments de structures.

XXX Mettre un exemple avec tous ces liens. XXX

Un mécanisme nouveau en SysML™ et important pour l’Ingénierie Système est le mécanisme d'allocation. Il permet de préciser quel élément conceptuel (comme un comportement ou une activité) est alloué sur quel élément physique.

Il est possible d’exprimer cette allocation de plusieurs manières.

Parler du <<AllocatedTo>>, compartiments des blocs et autres annotations. Parler des zones d’allocation dans les machines à états où les diagrammes d’activités par exemple. Parler des <<allocate>>.

C’est une forme particulière de Internal Block Definition (cf. [param]). On y retrouve les contraintes, déjà vues (cf. [contraintes]), mais cette fois-ci on a la représentation graphique des liens entre les données.

Il est regrettable que ce diagramme soit le moins utilisé (cf. [enquete]).

En résumé l’expression du comportement du système en SysML™ est très similaire à ce qui est fait dans UML™. On retrouve néanmoins le renforcement des liens entre éléments de modèles par les dépendances précises et les allocations. Un autre élément de renforcement entre éléments de modèles concerne le fait qu’un diagramme comportemental (comme une machine à état) est attachée à un élément bien précis (par exemple un bloc). Ces liens apparaissent entre blocs et machines à état, entre cas d’utilisation et diagrammes de séquence ou d’activité, etc.

Nous sommes des défenseurs des principes [DRY] et [TDD]. Nous allons donc réaliser nos diagrammes dans un outil et non "à la main" (de simples dessins). Nous choisissons ici l’outil TOPCASED pour des raisons que nous expliquerons ailleurs. La version utilisée pour réaliser les exemples de cette section est la version 5.2.

Un outil SysML™ seul ne suffit pas (cf. [outils]). Il faut penser à la documentation (cf. [gendoc]).

Il s’agit ici de décrire le contexte et d’identifier les principaux cas d’utilisation du système.

Chaque cas d’utilisation sera précisé (seq et act). Les données métier seront alors identifiées pour construire le modèle d’architecture logique (bdd et ibd) complété par la description des comportements complexes (stm). Enfin le modèle d’architecture physique permettra de déterminer les aspects déploiement et constructions physiques d'équipements/

Afin de consolider les différents modèles, les liens de traçabilité qui n’auront pas été déjà décrit
[Il est recommandé de ne pas attendre pour matérialiser ces liens, mais de les exprimés dès que rencontrés dans telle ou telle modélisation.]
seront rajoutés en insistant sur les liens :

Nous insistons dans l’ensemble de nos formations sur les approches test-driven, alors nous montrons dans cette section comment participer à la qualité du développement d’un système en formalisant (par exemple avec des diagrammes de séquence de scénarios à éviter) les test et les jeux de test.

Par exemple dans ce diagramme les blocs ne respectent pas la syntaxe graphique de SysML™ :

Pour rappel, la notation jmb : Personne permet de représenter un objet (une instance d’une classe ou d’un bloc). C’est donc une notation utilisée par exemple dans les participants d’un diagramme de séquence ou encore les parties d’un diagramme interne de bloc.

Donc dans le diagramme ci-dessus, l’acteur est correct (on peut mettre des acteurs dans un bdd, cf. OMG SysML v1.3 p.32), par contre les objets Block : … est une erreur de notation.

Plusieurs problèmes de non respect de la notation :

Il vaut mieux définir les cas d’utilisation du point de vue de (ou des) utilisateurs plutôt que du système. Cf. [Conventions]. Pour rappel, un cas d’utilisation est un regroupement de scénarios qui correspondent à un but d’un des acteurs (dans le domaine du problème considéré et selon la granularité envisagée).

Dans le diagramme ci-dessus il aurait fallut écrire :

Il faut faire attention à ne pas abuser des <<include>>. Par exemple ma recommandation en SysML/UML est de ne jamais avoir ça :

Dans la figure [UC2], il n’y a aucune raison de ne pas inclure le cas d’utilisation S’identifier directement dans le cas d’utilisation Acheter en ligne. Et avoir ainsi :

J’enseigne qu’un <<include>> devrait toujours concerner un cas inclut dans plusieurs autres, comme la figure [UC4] :

Néanmoins je vois deux raisons valables pour décomposer les cas d’utilisation avec des <<include>> qui se retrouvent isolés :

Faut-il minimiser le nombre de cas d’utilisation ou au contraire détailler? Normalement un bon diagramme des UC est indépendant de la solution, il exprime plutôt le problème (les attentes).

Néanmoins dans le cadre de l’enseignement en prépa comme support graphique à une analyse fonctionnelle, pourquoi pas détailler. À ce moment-là, utiliser des stéréotypes pour différencier les cas d’utilisation (<<TopLevel>> et <<Operational>> par exemple comme dans la documentation SysML 1.3 pp 185-186 sur le HybridSUV).

Attention à la notion d’héritage, complexe à appréhender. On ne peut surtout pas dire :

La relation doit pourvoir se lire "est un". Or, un SarmentAttaché n’est pas un SarmentNonAttaché (c’est même le contraire)!

Lorsque plusieurs blocs ont des caractéristiques en communs (propriétés, associations, comportement), il peut être utile de "factoriser" ces éléments en un bloc dont les autres vont "hériter". Quand on réalise ces liens hiérarchiques (on utilise souvent le terme "est un") en partant des blocs différents pour établir un nouveau bloc contenant les points communs on parle de généralisation. À l’inverse, quand on constate qu’un bloc possède réellement plusieurs déclinaisons différentes et que l’on créé alors des blocs spécifiques, on parle alors de spécialisation.

On retrouve cette association entre blocs, mais aussi entre acteurs, cas d’utilisation, etc.

Attention aux cardinnalités indiquées dans les associations.

SysML a repris (quasiment, cf. plus bas) tel quel le diagramme d'états UML :

À une exception près, les protocol state machines qui ont été retiré pour des raisons de simplification :

C’est important de faire référence à la norme quand on avance un fait. J’essaye de m’y atteler personnellement dans mes écrits. Néanmoins il faut faire attention car on fait souvent des citations qui finalement ne sont que des extraits.

qui peuvent se retrouver dans des manuels d’outils qui ne respecteraient pas la norme justement!!

Il faut donc bien faire attention avec les extraits de norme.

serait peut-être le diagramme d’activité.

Voir aussi la FAQ Comment traduire un grafcet en machine à état ?.

Tout simplement à relier les autres diagrammes à ce cas d’utilisation. Par exemple le comportement du système, l’architecture, etc. (les solutions) pourront être reliées (<<satisfy>>) à ce cas. Il faut aussi ne pas perdre de vue qu’un diagramme peut évoluer. On pourra très bien rajouter au diagramme des cas non encore pris en compte comme Transporter le système, Recycler le système, etc.

Pour la comprendre il ne faut pas utiliser le Larousse français (qui rend presque le caractère réciproque obligatoire), mais plutôt la comprendre dans son acceptation informatique (comme dans "Interaction Homme-Machine"). Par exemple un message (appel de méthode) d’un élément vers un autre dans un diagramme de séquence est appelé en SysML une interaction.

SysML permet de préciser le caractère réciproque ou non de l’interaction par exemple entre un Acteur et un Cas d’utilisation :

On pourrait les considérer comme des acteurs en se fiant à la définition (cf. Acteurs) et en les associant à des environmental entities. Mais elles sont échangées avec les entités de l’environnement, ce qui n’est pas la même chose. Autrement dit, il faut indiquer qui fournit les matières premières et qui recueille les matières produites. Eventuellement on peut les retrouver dans le diagramme de contexte ou encore dans un diagramme structurel comme le diagramme de bloc interne.

Pour alimenter le débat, je renvois aux exemples donnés par Loïc Féjoz lors de la journée UPSTI.

On pourrait croire que ces schémas sont identiques mais pas du tout. SysML™ présente juste l’organisation du modèle et non l’arbre alors que SysML™ permet de repousser ce choix voir d’explorer des alternatives.

pour l’intégrer ici.

Il faut bien faire la différence entre :

Non. Le lien de containment est en fait une action qui place le "contenu" dans le "contenant". Dans TOPCASED, le diagramme laisse les liens précédents à l'écran, mais dans le modèle, c’est bien le dernier containment réalisé qui est pris en compte. Dans la figure ci-dessous le lien A-C a été "dessiné" après celui B-C.

(En lien avec la question précédente)

L’organisation SysML™ des requirements est en fait un arbre. Pour réaliser ce "partage" certains utilisent un lien <<copy>> pour créer plusieurs copies d’un même requirement. Personnellement je n’aime pas cette solution.

Techniquement oui (<<satisfy>> étant dérivé de <<dependency>>), mais ça n’a pas beaucoup de sens que de dire qu’un besoin est satisfait par un autre. Il s’agit le plus souvent d’un lien <<deriveReqt>>.

La norme n’impose pas de sémantique précise à <<deriveReqt>>. Il y a généralement deux interprétations.

Autre exemple respectant 1 mais pas 2 : "Le véhicule doit posséder 4 roues." est dérivé de "Le véhicule doit se déplacer sur route." En effet, un aéroglisseur répondrait aussi l’exigence initiale et n’a pourtant pas de roues.

Quant au <<refine>> il est utilisé pour indiquer qu’un élément de modèle (qui peut être lui-même un requirement) est un raffinement (au sens niveaux d’abstraction, du plus abstrait au plus concret) d’un requirement. Par exemple, un use case ou un diagramme d’activité peut être un raffinement d’une exigence fonctionnelle (textuelle par exemple).

Il est utilisé pour indiquer que l’on souhaite conserver un lien de traçabilité entre les éléments (par exemple entre un élément de modélisation et un document). Il est recommandé d’utilisé une de ces versions plus précises (<<deriveReqt>> ou <<satisfy>> par exemple).

Verson 1.3 et disponible à l’URL: http://www.sysml.org/docs/specs/OMGSysML-v1.3-12-06-02.pdf

(en lien avec la question précédente)

Les changements notables par rapport à la 1.2 concernent :

Comment SysML™ permet de vérifier et de valider les exigences ?

La validation d’une exigence est de la responsabilité des parties prenantes. À partir de la spécification des exigences, ils valident qu’il s’agit bien du bon produit à construire. Typiquement, le diagramme des exigences sert de base à cette validation.

La vérification d’une exigence est de la responsabilité de l’ingénieur système et/ou de l’analyste système. C’est à eux de montrer la correspondance entre les éléments constituant du système et les exigences spécifiées. C’est principalement pour cette activité que sont utilisés les relations <<satisfy>> et <<verify>>.

Quelques autres questions que je laisse à votre sagacité :

SysML™ n’est pas un programme qu’on installe. Il existe de nombreux outils qui chacun possède sa propre façon d'être installé sur votre machine (en fonction de votre système d’exploitation, si c’est un plugin, etc.).

Les diagrammes SysML™ ne sont que des dessins, des représentations graphiques, ils ne s'exécutent donc pas. Bien sûr de nombreux travaux et outils portent sur les modèles exécutables. Il s’agit alors pour un outil de proposer de reproduire la dynamique d’un diagramme. Il s’agit en général de diagramme de comportement (par exemple une machine à état) pour lequel l’outil propose de simuler l’arrivée d'événement et de reproduire (plus ou moins graphiquement) le comportement modélisé (par exemple le franchissement d’une transition).